The following abbreviations are herewith defined, at least some of which are referred to within the following description of the prior art and the present invention.    3GPP 3rd Generation Partnership Project    CAMEL Customized Applications for Mobile Networks Enhanced Logic    CS Circuit Switched    CSCF Call Session Control Function    GUP Generic User Profile    HSS Home Subscriber Server    IP Internet Protocol    IP-CAN IP Connectivity Access Network    IM IP Multimedia    IMS IP Multimedia Subsystem    LTE Long Term Architecture    PS Packet Switched    PPA Push-Profile-Answer    PPR Push-Profile-Request    SAA Server-Assignment-Answer    SAR Server-Assignment-Request    S-CSCF Serving CSCF    SDP Session Description Protocol    SIP Session Initiation Protocol    UE User Equipment    UML Unified Modeling Language    URI Uniform Resource Identifier    WLAN Wireless Local Area Network
Referring to FIG. 1 (PRIOR ART), there is a diagram illustrating a 3GPP network 100 which has a traditional HSS 102 that is coupled to a CS domain 104, a PS domain 106 and an IM CN subsystem 108. The 3GPP network 100 is described in detail within the 3GPP TS 29.228 V7.5.0 entitled “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP Multimedia (IM) Subsystem Cx and Dx Interfaces; Signalling Flows and Message Contents (Release 7)”, dated March 2007 (the contents of which are incorporated by reference herein). As such, those skilled in the art are familiar with the architecture and functionality of this particular 3GPP network 100. Thus, for clarity, only the HSS 102 and the IM CN subsystem 108 (in particular a CSCF 110 and an application server 112) which are relevant to the present discussion are discussed in detail herein while the other well known components like the GMSC, MSC/VLR, SGSN, GGSN, OSA SCS, IM-SSF etc. . . . are not discussed in detail within this document. The CSCF 110 is the entity within the IM CN subsystem 108 that is involved in establishing user call/sessions with UEs 114 (only one shown). The application server 112 is the entity within the IM CN subsystem 108 that provides an IMS service to the UE 114.
The HSS 102 has a master database 103 which stores information related to the users and their respective UEs 114 in the 3GPP network 100. For the sake of simplicity, user and user equipment are generally referred to as the same and have often been identified as UE 114 throughout the present document, so that the information stored in the master database 103 on a user basis is generally referred to as user data irrespective of whether such data is associated with the user or their respective user equipment. For instance, the HSS 102 incorporates the 2G/3G Core network HLR functions in addition to other functions related to accesses like the user control IP Multimedia Subsystem (IMS) functions, CS functions, PS functions, WLAN functions etc. . . . In particular, the HSS 102 supports the following functions: (1) mobility management; (2) user security information generations; (3) user security support; (4) service provisioning support; (5) call/session establishment support; (6) GUP data repository; (7) identification handling; (8) service authorization support; (9) access authorization; (10) application services support; and (11) CAMEL services support. Basically, the HSS 102 has become a privileged point in the 3GPP network 100 where many different accesses meet.
The traditional HSS 102 also has multiple tasks and one of those tasks is to handle the service profile 116 for the IMS UE 114 which receives an IMS service from the IM application server 112. For instance, the HSS 102 downloads the service profile 116 to a serving CSCF 110 (hereinafter S-CSCF and in particular the S-CSCF 110) assigned for serving the UE 114 when the UE 114 registers with the IM CN subsystem 108. The S-CSCF 110 then uses the service profile 116 to invoke the IMS service for the UE 114. The HSS 102 would also download the service profile 116 to the S-CSCF 110 whenever an operator administratively changes data related to the UE 114. A discussion about the contents of the traditional service profile 116 is provided next but for a more detailed discussion about the traditional service profile 116 reference is made to Annex B in the aforementioned 3GPP TS 29.228 V7.5.0
Referring to FIG. 2A (PRIOR ART), there is a diagram illustrating an outline of a UML model for the traditional service profile 116 that is currently specified in 3GPP TS 29.228 V7.5.0. As shown, the traditional service profile 116 has the following: (1) a Public Identification class 202; (2) a Core Network Service Authorization class 204; (3) an Initial. Filter Criteria class 206; and (4) a Shared IFC Set class 208. The IFC class 206 is relevant to the present discussion because it contains the mechanisms that are used by the S-CSCF 110 to invoke the IMS service for the UE 114. Thus, the IFC class 206 is described in detail below while the Public Identification class 202, the Core Network Service Authorization class 204, and the Shared IFC Set class 208 will not be discussed in detail within this document.
Referring to FIG. 2B (PRIOR ART), there is a diagram illustrating an outline of the UML model of the IFC class 206 currently specified in 3GPP TS 29.228 V7.5.0. The IFC class 206 has zero to n IFC instances 206′ (one shown) each of which is composed of zero or one instance of a Trigger Point class 210 and one instance of an Application Server class 212. Each IFC 206′ has a priority attribute that indicates the priority of the filter criteria where the higher the priority number then the lower the priority of the filter criteria. For example, an IFC 206′ with a higher value of priority number would be assessed after the IFC 206′ with a smaller priority number has been assessed. Plus, each IFC 206′ has a ProfilePartIndicator attribute that is an enumerated type, with possible values “REGISTERED and UNREGISTERED”, which indicates if the respective filter is a part of the registered or unregistered user service profile 116.
The Trigger Point class 210 describes trigger points that are checked by the S-CSCF 110 to find out if the indicated application server 112 (for example) should be contacted or not to provide an IMS service to the UE 114. Each trigger point 210 is composed of 1 to n instances of the Service Point Trigger class 214 (hereinafter SPT or SPT class). Plus, each trigger point 210 is a boolean expression in Conjunctive or Disjunctive Normal form (CNF of DNF). In particular, each trigger point 210 has a ConditionTypeCNF attribute that defines how the set of corresponding SPTs 214 are expressed, i.e. either an ORed set of ANDed sets of SPT statements or an ANDed set of ORed sets of statements. These combinations are termed, respectively, Disjunctive Normal Form (DNF) and Conjunctive Normal Form (CNF). Both DNF and CNF forms can be used. In the absence of a trigger point class 210, this would indicate an unconditional triggering of the indicated application server 112.
The Application Server class 212 indicates the application server 112 (for example), which is contacted, if the trigger points 210 and SPTs 214 are met. The Application Server class 212 has a ServerName attribute which contains the SIP URL of the application server 112 (for example). The Application Server class 212 also has a Default Handling attribute which indicates whether the dialog with the UE 114 should be released if the application server 112 could not be reached. The Default Handling attribute is enumerated and can take the values: SESSION_CONTINUED or SESSION_TERMINATED. In addition, the Application Server class 212 contains zero or one instance of a Service Information class 216. The Service Information class 216 has a ServiceInfo attribute and allows the download of information to the S-CSCF 110 where the downloaded information is to be transferred transparently to an application server 112 when the trigger points 210 of the corresponding IFC 206′ are satisfied.
Referring to FIG. 2C (PRIOR ART), there is a diagram illustrating an outline of an UML model of the SPT class 214 currently specified in 3GPP TS 29.228 V7.5.0. The SPT class 214 has one to n SPT instances 214′ (one shown) where each SPT 214′ has a Group attribute that allows the grouping of SPTs that will configure the sub-expressions inside a CNF or DNF expression. For instance, in the following CNF expression (A+B)·(C+D), A+B and C+D would correspond to different groups. In CNF, the Group attribute identifies the ORed sets of SPT instances 214′. If the SPT 214′ belongs to different ORed sets, then that SPT 214′ can have more than one Group value assigned. At least one Group is assigned for each SPT 214′. In DNF, the Group attribute identifies the ANDed sets of SPT instances 214′. If the SPT 214′ belongs to different ANDed sets, then that SPT 214′ can have more than one Group value assigned. At least one Group is assigned for each SPT instance 214′. Plus, each SPT 214′ also has a ConditionNegated attribute which defines whether the corresponding instance is negated (i.e. NOT logical expression). Plus, each SPT 214′ has a RegistrationType attribute which is relevant only to the SIP Method 216 (discussed below) that has a value of “REGISTER” (note: the support of the RegistrationType attribute is optional in the HSS 102 and in the S-CSCF 110).
Moreover, each SPT 214′ includes the following: (1) Request-URI class 218; (2) SIP Method class 216; (3) SIP Header class 220; (4) Session Case class 222; and (5) Session Description class 224. The Request-URI class 218 contains a RequestURI attribute and defines a SPT for the Request-URI. The SIP Method class 216 contains a Method attribute and defines a SPT for the SIP method. The SIP Header class 220 contains a Header attribute and a Content attribute which define a SPT for the presence or absence of any SIP header or for the content of any SIP header. The Session Case class 222 is an enumerated type, with possible values “Originating”, “Terminating_Registered”, “Terminating_Unregistered”, “Originating_Unregistered” which indicate whether the filter should be used by the S-CSCF 110 handling the Originating, Terminating for a registered end user 114, Terminating for an unregistered end user 114, or Originating for an unregistered end user 114. The Session Description Information class 224 has a Line attribute and a Content attribute which define a SPT for the content of any SDP field within the body of a SIP Method.
In view of FIGS. 2A-2C (PRIOR ART), it can be seen that the service profile 116 has one or more IFCs 206′ which are the mechanism that is downloaded to and then used by the S-CSCF 110 in the IMS Core 108 to invoke an IMS service for the UE 114 (only one shown). Basically, the IFCs 206′ identify the particular IMS application server 112 that has to be invoked by the S-CSCF 110 and what must be done if that particular INS application server 112 is not available. In addition, the IFCs 206′ include one or more SPTs 214 which specify under which conditions the identified IMS application server 112 shall be involved in a SIP session such that the IMS service can be invoked for the particular UE 114.
In particular, the S-CSCF 110 when handling a SIP request for the UE 114 (or the IMS application server 112 on behalf of the UE 114) goes through the list of prioritized IFCs 206 and the corresponding SPTs 214 within the service profile 106. And, when the conditions in the IFCs 206 and the corresponding SPTs 214 are satisfied according to the information in the SIP request then the S-CSCF 110 contacts the IMS application server 112 that was indicated in the Application Server class 212 to invoke the SIP request. Generally speaking, the IFCs 206 are related to SIP messages and SIP procedures and, consequently, the conditions specified in the corresponding SPTs 214 are also related to the contents of the SIP messages and the SIP procedures. This can be seen by the fact that the SPTs 214 which have been standardized to date include the Request-URI 218, the SIP Method 216 (e.g. INVITE), the SIP Header 220 (for the presence or absence of any SIP header or for the content of any SIP header), the Session Case 222 (an enumerated type, with possible values “Originating”, “Terminating_Registered”, “Terminating_Unregistered”, “Originating_Unregistered”), and the Session Description 224 (for the content of any SDP field located within the body of a SIP Method) (note: SDP is a format for describing streaming media initialization parameters and is discussed in detail within IETF's RFC 4566).
However, there is high interest today to take into account other information and not only SIP information that is related to the specific SIP request which is received by the S-CSCF 110 to invoke an IMS service for the UE 114. For example, today it is not possible to take into account the CS status (GSM attached, etc. . . . ) of the UE 114 to decide whether one IMS application server 112 or another IMS application server should be involved in the SIP request. Accordingly, there has been and is a need to address this shortcoming and other shortcomings with the current state-of-the-art when invoking an IMS service for a particular UE. This need and other needs are satisfied by the present invention.